chore(cua-driver-rs)(nix): cargoLock.lockFile + sync Cargo.lock on bump (kill version drift) - #1934

The drift, and why it kept biting

The release bump (bump2version) edits only Cargo.toml's [workspace.package] version. It leaves Cargo.lock's 9 workspace-member versions stale, and the Nix package pinned a manual cargoHash that hashes the vendored lockfile. So the committed lock + hash stayed consistent (and green) only by never touching the lock — a frozen-inconsistent state that detonates the moment anyone runs cargo build: it re-locks the members, diverges from the committed lock, and invalidates the hash → every Nix job goes red. That's what hit #1933. The drift had silently accumulated across 0.5.3 → 0.5.6 (Cargo.toml said 0.5.6; Cargo.lock + package.nix still said 0.5.3).

Fix — three changes so it can't recur

1. package.nix uses cargoLock.lockFile instead of cargoHash. importCargoLock derives each dependency's fixed-output hash from the lockfile itself, so there is no hash to hand-maintain — Cargo.lock can change freely (version bump, dep update) and the build keeps working. I verified the old "apple crates may be unreachable from crates.io" rationale is false: apple-cf / apple-metal / objc2 are all registry+crates.io with checksums, and there are zero git deps (376 registry / 0 git), so no outputHashes overrides are needed.
2. package.nix reads version from Cargo.toml ([workspace.package]) instead of a hardcoded literal (which had drifted to 0.5.3).
3. Re-locked Cargo.lock to 0.5.6, and the bump workflow now runs cargo update --workspace after bump2version and folds the synced lockfile into the bump commit (moving the tag), so the manifest and lockfile ship in sync every release.

Verification

• CI: the Nix jobs build via cargoLock.lockFile (the load-bearing change — confirms importCargoLock vendors the full dep set with no hash). I can't run Nix on the dev box, so CI is the gate.
• The Cargo.lock diff is only the 9 workspace-member version bumps (0.5.3→0.5.6); no registry deps changed.
• The bump-workflow change can't run until the next release, but it's guarded (only acts if Cargo.lock changed; only for cua-driver-rs) and cargo is preinstalled on the runner.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Chores
  • Improved release automation and build configuration to ensure dependencies are properly synchronized during releases.
  • Enhanced build system to dynamically derive package version and dependencies from source configuration.